Technical FAQFrequently Asked Questions about the usage of KeePass. |
KeePass supports two different locations for storing configuration information: the global configuration file in the KeePass directory and a local, user-dependent one in the user's private configuration folder. Most likely you do not have write access to your global configuration file.
For more details, see Configuration.
Application icons are icons in Windows ICO format. They can be used in
Windows shortcuts and/or as file association icons. The KeePass executable
contains various application icons which can be used for these purposes. Additional application icons are available from the " Ext/Icons "
directory of the KeePass source code download.
Most of them, shown at right, are slight variations of the main KeePass icon.Even more, contributed icons (by users) can be found on the plugins page. If you have multiple KeePass databases, you can use differently colored KeePass application icons in order to distinguish them. These icons are not included in the binary distribution because this would make the application file too large. |
Client icons are the icons used for password entries and groups within KeePass.
Each entry can be assigned its own icon. You can import your own icons into KeePass databases. For this, click the 'Add...' button in the icon picker dialog. Images are automatically resized to 16x16, if they are larger or smaller. Supported formats are BMP, EMF, GIF, ICO, JPEG, PNG, TIFF and WMF. |
No, this is not possible. In order to edit attachments, you need to save them to a (temporary) file, edit it using an external application, import it back to KeePass as attachment, and finally delete the temporary file.
There will no feature be implemented that automates these steps, because of security problems. To see the problems, let's assume that KeePass would support editing attachments. When you click a button, KeePass would save the attachment to a file and open it using its associated external application. When the external application is closed, KeePass would import the temporary file and delete it securely. But what happens when KeePass is closed before the external application? KeePass cannot delete the file because it's eventually locked by the external application. Theoretically KeePass could tell the user this fact before closing, but what to do when the computer shuts down? Here, there's no time left to ask the user what to do. The temporary file would have been leaked, i.e. left unencryptedly on disk, which is obviously very bad.
One could argue that the leakage would only be temporary: at the next start, KeePass could scan the temporary directory for remaining files and delete them. Anyway, the files would be freely accessible (unencrypted) by all other applications during a complete computer shutdown and boot process. If you don't start KeePass on this computer ever again, the file is leaked forever. As KeePass is designed to be portable, i.e. may be securely used on many computers, this temporary leakage is unacceptable.
Is the Auto-Type feature resistant to keyloggers?
By default: no. The Auto-Type method in KeePass 2.x works the same as the one in 1.x and consequently is not keylogger-safe.KeePass automatically tries to lock its workspace when Windows is locked, with one exception: when a KeePass sub-dialog (like the 'Edit Entry' window) is currently opened, the workspace is not locked.
To understand why this behavior makes sense, it is first important to know what happens when the workspace is locked. When locking, KeePass completely closes the database and only remembers several view parameters, like the last selected group, the top visible entry, selected entries, etc. From a security point of view, this achieves best security possible: breaking a locked workspace is equal to breaking the database itself.
Now back to the original question. Let's assume an edit dialog is open and the workstation locks. What should KeePass do now? Obviously, it's too late to ask the user what to do (the workstation is locked already and no window can't be displayed), consequently KeePass must make an automatic decision. There are several possibilities:
Obviously, none of these alternatives is satisfactory. Therefore, KeePass implements the following simple and easy to understand behavior:
When Windows is locked and a KeePass sub-dialog is opened, the KeePass workspace is not locked.
This simple concept avoids all the problems above. The user is responsible for the state of the program.
Security consequence: the database is left open when Windows locks. Does this matter? Normally, you are the only one who can log back in to Windows. When someone else logs in (like administrator), he can't use your programs anyway. By default, KeePass keeps in-memory passwords encrypted, therefore it does not matter if Windows caches the process to disk at some time. So, your passwords are pretty safe anyway.
KeePass creates a temporary HTML file when printing password lists and showing print previews. This file is securely erased (i.e. overwritten multiple times before being removed from the file system tree) when closing the database.
You must wait for the file being printed completely before closing KeePass (and close the print preview before closing KeePass), otherwise it could happen that the printing application blocks KeePass from deleting the file.
There is no way around the temporary file in the current printing system. If you want to write a plugin that directly sends the data to the printer, you can find a plugin development tutorial here: KeePass 2.x Plugin Development.